前阿里中台架构师：基于中台架构的新业务建设原则
基于中台架构的新业务建设原则
数字化建设是一个长期持续的过程，在此过程中，中台能力不断沉淀、增强，产品功能越来越多，新的产品也会随着业务的不断发展逐渐增加。要让这些新的产品和功能在不断建设以满足业务发展要求的同时，还能完成中台架构持续沉淀数字资产的使命，给企业带来持续的高效业务支撑，就需要对这些新的产品建设提出一些假设原则和标准规范。
从组织人才角度来说，不是所有传统企业都像互联网或者集团型企业那样能拥有大量的架构设计和开发人员，所以很难将中台的运营模式从互联网公司照搬到企业中，但企业中台作为企业将来最为核心的数据资产的重要性已经不言而喻，所以笔者建议有能力的企业应拥有一个自己的技术团队，核心职能不是像以前那样进行企业各种业务系统的开发建设，而是着重于中台的服务能力运营。
如果有些企业的IT部门在短期内没办法建设和拥有自己的开发技术团队，则务必寻找到一个与企业建立可持久、紧密的合作关系的战略级IT服务提供商，企业IT部门的人员一定要行使好各服务中心业务发展方向把关的职能，并对技术的架构有清晰的掌控，IT服务提供商则提供较为纯粹的技术开发工作，这样才能保证中台在有效运营的情况下，在核心业务发展上做到企业自主可控。
所以，如果企业中台的核心运营团队是企业自身的技术团队，那么企业与IT服务商间合作出现问题、服务人员流失、数据安全等因素对中台业务的影响将降到最低。
对于前台业务的系统建设，应秉承业务数据的统一、实时、在线以及业务沉淀的原则，新建业务系统应基于中台现有的服务能力进行构建，此时就不要奢望所有的系统都由企业自己的技术团队开发，这不单单是出于人才成本上的合理性考虑，而且确实有些业务系统所涉及的领域非常专业，企业业务部门的同事都未必能将该领域的业务需求梳理得非常清楚，就很难进行自主开发了。从中台架构在传统企业中过去几年的实践来说，确实基于所建业务的专业性、企业对自身业务的理解深度、系统上线时间等
原因，不能完全遵循中台建设的原则进行系统建设，从这些实践中，针对企业新建系统类型和建设条件的不同，大致总结出了以下几种建设方式。
1.自有技术团队+软件外包人员联合开发模式
在企业对于业务需求有比较系统化的理解和把控能力的情况下，就完全应该基于中台已有的服务能力和开发规范进行系统的开发建设，使得新建系统能很好地融入企业的中台体系之中。但对于任何企业，在技术开发人员上投入的成本都相对较高，
所以笔者不建议企业中所有业务系统都由自己的开发人员去实现，而是在这些系统的建设过程中，让业务和技术架构师、核心开发人员来自企业自身的IT技术团队，这样可在业务、技术架构层面对系统建设有总体的把控，之后，具体的业务逻辑可以让软件外包人员实现，很多互联网公司在过往很长一段时间也都是采用这样的方式。
这样就能实现新的业务也基于中台架构，拥有前面章节所阐述的中台架构带来的各种优势和价值，在对系统核心业务有把控的同时，总体人员成本会降低不少，也不会出现系统并行建设或上线系统越来越多，企业所需的开发人员呈现线性增长的情况。
2.引入专业解决方案提供商，遵循中台架构建设
在企业自身的业务部门和技术团队都对该业务领域没有足够的理解和需求把握的情况下，可以采用招投标的方式，选择出对企业目前新建系统的业务需求更理解、具备该领域专业能力的解决方案提供商，让他们基于企业中台的服务设计、开发、数据库设计等规范进行开发。
在此过程中，企业的技术和业务人员应抓住难得的业务学习机会，深入系统的需求梳理、设计、开发、建设阶段，而不能像之前那样只负责项目管理以及资源协调等工作，目的是尽快对该系统的业务领域有一个全面的掌握，并起到对该系统在业务发展方向的把控作用，逐渐构建起在该业务领域的业务深度，最终达到与第一种方式相同的效果，企业自己的业务运营和技术人员能全局把控该系统的运营和发展方向，行业解决方案商可继续提供该系统的开发运维及功能升级等服务。
采用这样的方式既能在短期内借力（毕竟这些专业的解决方案提供商多年来在专业领域中沉淀了很好的业务知识和最佳实践），也能很好地保持中台架构的建设阵型。随着企业人员对该业务领域的不断学习和沉淀，最终将这块业务完全按照企业中台发展的要求纳入整个中台体系之中。
3.引入商业套件，实现中台服务能力与套件的业务对接
在上一个方式中，所选择的专业解决方案提供商很可能有自己成熟的产品，相比于完全自定义开发的方式，基于“商业套件+适量”的定制开发能给这些专业解决方案提供商带来更大的利润，减少每个项目的投入周期和成本。而且有些专业系统确实需要多年的沉淀和打磨才能形成，比如产品设计管理系统、非常专业的设计建模工具，整体系统没办法在短期内基于中台架构进行重构。不管解决方案提供商是出于项目利润还是本身系统融入中台架构的改造成本的考虑，都势必会将这部分成本转嫁到企业，使得企业构建系统的成本大幅上升。
从企业IT投入产出比的角度来说，对于这样的情况，就只能退而求其次，采用商业套件进行定制的方式，在套件现有的API基础上，通过ESB或API集成网关实现套件与中台现有的服务能力互联。
采用这样的方式确实在某种程度上无法实现真正的数据实时、统一、在线，接下来应该借鉴第二种建设方法，企业自己的员工在系统建设和使用中学习专业知识，使该专业能力真正由企业自身掌握，再发挥“学、赶、超”的精神，帮助企业在该业务领域构建起自身独特的竞争优势。
这里想说，企业在学习和掌握了这些专业套件中的业务精华后，不一定要把这些商业套件推倒重建，笔者认为是否要推倒重建主要取决于以下两点：
商业套件与中台架构间采用传统的系统集成方式，因为无法真正做到数据的实时、统一、在线，给企业在关键的业务链环节优化带来重要影响。
商业套件所提供的用户体验、业务响应能力无法满足企业高速发展的要求，也无法很好地承担起让企业业务长远发展的重任。
任何系统推倒重建都会给企业带来人力和开发的成本投入，也会给业务支持多少带来一些影响，任何IT投入都应给企业解决实际的问题，创造真正的商业价值。如果一个软件套件可以很好地行使职能，没有阻碍企业业务的发展，那就依然保持现有系统的运转状态，直到该系统自身的发展满足不了企业发展的需求，再进行推倒重建，此时企业也具备了对该业务领域足够的了解并能清晰地分析业务需求，具备了将该系统基于中台架构进行建设的条件。
《数字化转型的道与术：以平台思维为核心支撑企业战略可持续发展》
中台圣经——《企业IT架构转型之道》作者钟华新作！十余年数字化实战经验再升华！开创性提出数字化转型中平台思维的十大要素。来自实践，并能指导实践。系统化介绍数字化转型的思路与方法，以及产业互联网平台的建设思路，为各种业务模式的数字化转型提供高价值参考。
加入技术琐话读者群讨论，请在公众号回复关键词：读者群。
往期推荐
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。